With the explosion in the use of computer networks for electronic communications/transactions there is a growing need for systems that render such communications/transactions secure and authenticatable. The state of the art is to build network security on the foundation of a conventional Public Key Infrastructure (PKI), where each communication or transaction is encrypted, and/or authenticated. For example, in order to ensure that only Bob will be able to decipher a message, Alice encrypts the message with Bob's public encryption key. Only Bob's private decryption key can reveal the contents of a message encrypted with Bob's public encryption key. Similarly, in order to provide assurance to Bob that a message came from Alice, Alice signs the message with her private signing key. Since Alice's public signature verification key shows the message to be unmodified, Alice's private signing key must have been used to produce the signature.
Public key cryptography is effective when used by a small number of parties, but when used on a network-wide basis, as in conventional PKI, it quickly becomes unwieldy due to key management issues. Due to its scaling problems, it would be difficult to use conventional PKI to support a broad range of electronic communications applications and transactions, including financial transactions, workflow applications, electronic sales, online insurance, and database transactions. Some shortcomings of conventional PKI are now described in the context of e-mail, which is the quintessential electronic communication application and representative of the broader class of electronic transactions.
Most current electronic mail (hereinafter, "e-mail") (or other electronic communication) technology adheres to an end to end paradigm in which one user sends an electronic message directly to another user without significant intervention by other computers or agencies in the delivery path. In many such systems a user can encrypt, decrypt or sign a message; or verify an electronic signature using encryption software (such as PGP or S/MIME) running on the client or the server. In the latter situation the server performs cryptographic functions for a user using key/signature information (private keys of the user and public keys of his correspondents) maintained for the individual on the server and then routes the message to either an input or output mail queue as appropriate. In contrast, when the client performs the cryptographic functions, the server performs only the message routing functions. As a result of the server's minimal involvement in e-mail processing, corporate policies (such as who can represent the corporation in which matters and who is entitled to use which badges of corporate authority) are difficult to implement at the server level.
For example, it would be useful for a company president to be able to use the electronic equivalents of paper processes to issue official corporate statements. For such statements to be trusted inside or outside the company, no other employee should be able to misrepresent herself as the president and anyone receiving the official e-mail should be able to authenticate the message as coming from the president on behalf of the company. Ideally, this authentication would be provided by the e-mail server, or some other centralized server. However, this is not presently possible in conventional e-mail systems, in which users can represent themselves in any manner and, generally, there is a lack of trusted/authoritative e-mail connections between e-mail servers.
The president might also want to send e-mail in an individual capacity (to a friend, for example) or as a corporate employee (e.g., when posing an insurance benefits question). It would be desirable for the president to issue such messages without representing herself as president, but as one of her other roles (e.g., individual or employee). However, because conventional e-mail systems are individual user-oriented, it would be difficult for corporate e-mail systems to take into account the corporate roles (e.g, President, Vice President, CFO, manager, exempt employee, non-exempt employee, check signer, etc.) of e-mail users. Because most corporate policies are role-based rather than individual-based (e.g., all check requests for more than ten thousand dollars must be signed by the CFO, only the President can use "From the desk of the President" letterhead etc.) this orientation further frustrates the ability of conventional e-mail systems to implement corporate policies. This lack of a role-based e-mail infrastructure also prevents the various authorities of the corporation from being projected internally or externally via e-mail or other communication medium.
Moreover, the focus of current encrypted E-mail products on support for the individual user complicates key management. For example, given that many individual users will have their own unique keys for each different encryption system (e.g. PGP, S/MIME, etc.) and the keys for all external contacts, thedirectory for a corporate e-mail service might need to keep track of tens of thousands of keys. The current products provide little support for maintaining or updating this database as correspondents change their addresses, update their software, or replace their keys, particularly across corporate boundaries.
Additionally, even if encrypted e-mail systems were somehow modified to account for roles, their decentralized (i.e., client-oriented) nature would prevent roles from being easily transferred or delegated, for example, delegating the authority of the president when the president is on vacation or temporary authority to a customer to access the relevant set of help files or transferring the authority of president to a new person. This lack of role support in encrypted e-mail systems is also a barrier to implementing secure workflow processing in the corporate e-mail server, where, for example, a travel request might need to be signed off on by one or two supervisors depending on the cost of travel and, in the absence of one or two of the required signers, by the CFO. Moreover, another problem with current encrypted email systems is accurate revocation. For example, in such systems it would be possible for a company to revoke the president's key (e.g., after she quit), delegitimizing encrypted e-mail legitimately sent by the president before she quit (assuming the company also sent out notices to all correspondents that the president had quit). Alternatively, it would be possible for the ex-president to keep using the president's key long after leaving the company.
Thus, the end to end paradigm of conventional e-mail prevents the effective use of e-mail in a corporate context in at least seven ways: (1) it frustrates corporate control over how users represent themselves, (2) it does not support an environment in which the corporate authority wielded by an employee/user is determined by his corporate role and not his individual identity, (3) it does not support an environment in which an employee can have multiple simultaneous roles (4), it does not support the delegation or transfer of authorities, (5) it complicates encryption and key management (for example, key revocation-when a key is compromised or has expired, key update-when a key is replaced, and key distribution), and (6) it complicates workflow processing and (7) it allows keys to be used after revocation indistinguishably from their use at approved times (i.e., it provides no information about which action taken by a revoked key are valid and which are invalid).
It is therefore an objective of the present invention to provide an alternative to prior art conventional PKI systems and an e-mail application in it that supports: (1) corporate control over how users represent themselves, (2) an environment in which the corporate authority wielded by an employee/user is determined by his corporate role and not his individual identity, (3) an environment in which an employee can have multiple simultaneous roles, (4), the delegation and transfer of authorities, (5) simplified encryption and key management, (6) simplified workflow processing and (7)prompt revocation of authorities (eliminating the need for receiver online verification of authority).